Gateway system to interface different communication networks

ABSTRACT

A first communication network transfers a signaling message for a call to a second communication network. The signaling message indicates a first identifier that represents a connection through the first communication network to the second communication network. The second communication network processes the signaling message to select a second identifier. The first communication network transfers a user communication for the call to the second communication network. The user communication has a header indicating the first identifier. In response to the first identifier, the second communication network modifies the first identifier in the header to the second identifier. The second communication network transfers the user communication to a destination node in response to the second identifier in the header of the user communication.

CROSS-REFERENCES

This patent application is a continuation of U.S. patent applicationSer. No. 10/686,221, filed on Oct. 15, 2003; which is a continuation ofU.S. Pat. No. 6,683,878, filed on Apr. 10, 2002; which is a continuationof U.S. Pat. No. 6,529,514, filed on Sep. 9, 1999; which is acontinuation of U.S. Pat. No. 6,026,091, filed on Jul. 27, 1998; whichis a continuation of abandoned U.S. patent application Ser. No.08/594,661, filed on Feb. 2, 1996; which is a continuation-in-part ofU.S. Pat. No. 5,825,780, filed on Dec. 7, 1995, which is a continuationof abandoned U.S. patent application Ser. No. 08/238,605, filed on May5, 1994; and which are all hereby incorporated by reference into thisapplication.

BACKGROUND

Current ATM communications systems may transport communications trafficover switched virtual circuits (SVC) or permanent virtual circuits(PVCs). SVCs are set-up and torn down as requested—like telephone calls.PVCs are provisioned through an ATM network and are used like adedicated communications channel. Aside from PVCs and SVCs, PermanentVirtual Paths (PVPs) and Switched Virtual Paths (SVPs) are alsoavailable. The use of SVCs or SVPs typically results in more efficientuse of ATM bandwidth. As is known, ATM communications paths arelogically designated by the Virtual Path Identifier (VPI) and theVirtual Channel Identifier (VCI) located in the ATM cell header.

ATM cross-connect devices route ATM traffic by associating virtualconnections. A cross-connect associates two virtual connections bychanging the VPI/VCI of ATM cells from one virtual connection to theVPI/VCI of the other virtual connection. For PVCs or PVPs, these routeshave been pre-provisioned. This means that the routing configuration isset and remains static. Typically, a cross-connect has multiple routingconfigurations that are stored in memory. Network administration canselect different routing configurations, but changes are not implementeddynamically on a call-by-call basis. In any event, the number of routingconfigurations required to support call routing would be prohibitivelycomplex. In a provisioned cross-connect, the VPI/VCIs in incoming cellsare changed to pre-assigned VPI/VCIs.

SVCs and SVPs are handled differently. Since the VPI/VCIs are set-up andtorn down frequently, provisioned routing configurations withpre-assignments of VPI/VCIs are not possible. For SVCs and SVPs, theVPI/VCIs are dynamically selected in real time on a call-by-call basisby an ATM switching function. The switching function makes theselections by processing of information in telecommunications signaling.An example of such signaling is B-ISUP signaling.

Some ATM systems use pre-provisioned PVPs to connect the networkelements, and then dynamically select SVCs within the PVPs. In this way,network elements can each be interconnected by PVPs to form a flatarchitecture, and SVCs can be dynamically allocated to maximizeefficient use of bandwidth. In this environment, problems are causedwhen one network is connected to another network. Current signalingcapability required by the switching function is not able to handle highvolumes of traffic. This impairs the ability of separate networks todynamically allocate SVCs between multiple cross-connects on acall-by-call basis. As for the PVPs, extensive administrativeinformation must be shared to coordinate all of the PVP provisioningbetween the two networks. An additional coordination problem occurs withsignaling between networks. When networks interface at multiple points,signaling routes must be defined so each interface point can signal theopposing interface points.

One solution is to install complex ATM switches with full signalingcapability. At present, such devices are not readily available at thequality and cost required for a robust and cost-effective deployment.There is a need for a cost-efficient system to interface between two ATMnetworks and alleviate the problems described above—namely thecoordination of PVPs and SVCs.

Gateways are devices that interface different networks or systems. Theyallow interconnection between different networks that are notcoordinated. Some examples are Internet Protocol (IP) bridges and X.75gateways. But, these systems are not able to interface PVPs and SVCs oftwo ATM networks. These devices are not capable to handle ATM.Additionally, they are not designed to handle the dynamic allocation ofconnections required for SVCs. Thus, an ATM gateway is needed tointerface two ATM networks. This ATM gateway must be able to handle thedynamic allocation of VPI/VCI connection assignments required to supportSVCs.

SUMMARY

A first communication network transfers a signaling message to a secondcommunication network for a call. The signaling message indicates afirst identifier that represents a connection through the firstcommunication network to the second communication network. The secondcommunication network processes the signaling message to select a secondidentifier. The first communication network transfers a usercommunication for the call to the second communication network. The usercommunication has a header indicating the first identifier. In responseto the first identifier, the second communication network modifies thefirst identifier in the header to the second identifier. The secondcommunication network transfers the user communication to a destinationnode in response to the second identifier in the header of the usercommunication.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a version of the present invention.

FIG. 2 is a block diagram of a version of the present invention.

FIG. 3 is a block diagram of a version of the present invention.

FIG. 4 is a logic diagram of a version of the invention.

FIG. 5 is a logic diagram of a version of the invention.

FIG. 6 is a message sequence chart for a version of the invention.

FIG. 7 is a message sequence chart for a version of the invention.

FIG. 8 is a message sequence chart for a version of the invention.

FIG. 9 is a message sequence chart for a version of the invention.

FIG. 10 is a message sequence chart for a version of the invention.

FIG. 11 is a message sequence chart for a version of the invention.

FIG. 12 is a message sequence chart for a version of the invention.

FIG. 13 is a message sequence chart for a version of the invention.

DETAILED DESCRIPTION

For purposes of clarity, the term “connection” will be used to refer tothe transmission media used to carry user traffic. The term “link” willbe used to refer to the transmission media used to carry signaling. Onthe Figures, connections are shown by a single line and signaling linksare shown by double lines.

FIG. 1 depicts a version of the present invention. Shown are signalingand control system 100, ATM system 120, ATM system 140, and gateway 130.These components are connected by connections 160-161 and linked bylinks 150-152 as shown. Those skilled in the art are aware that largenetworks have many more components than are shown, but the number ofthese components has been restricted for clarity. The invention is fullyapplicable to large networks.

ATM systems 120 and 140 are known in the art. They typically include ATMconnections, cross-connects, and switches. Any source of ATM cells iscontemplated by the invention. At least one of the ATM systems will havethe need to control the VPI/VCIs of cells entering the network. This isbecause the cells entering the network have VPI/VCIs designated by thepreceding network. These VPI/VCIs are not necessarily compatible withthe routing configuration of the subsequent network accepting the cells.As such, the VPI/VCIs must be modified to be compatible the new VPI/VCIrouting configuration. This is especially true if the ATM network ishandling SVCs without an ATM switch to process signaling and select theproper SVCs in real time. If only pre-provisioned cross-connects areused, the VPI/VCI in the incoming cell effectively selects the VPI/VCIthe cell will have when it exits the cross-connect. If SVCs are to bedynamically allocated on a per call basis through pre-provisionedcross-connects, a system is needed to modify the VPI/VCIs to allocateSVCs before the cells enter the cross-connect.

Gateway 130 provides this capability. Gateway 130 receives ATM cellsentering a network and converts the VPI/VCIs in the cells so they arecompatible with network routing configuration. Gateway 130 would modifythe VPI/VCIs of cells entering ATM system 140 on a call-by-call basis.This allows for the allocation SVCs. Gateway 130 could also operate in atwo-way fashion. This means it will modify the VPI/VCIs of cellsentering ATM system 120 according to ATM system 120 requirements, and itwill modify the VPI/VCIs of cells entering ATM system 140 according toATM system 140 requirements. Gateway 130 is capable of modifyingVPI/VCIs based on control instructions from signaling and control system100.

Signaling and control system 100 receives signaling passed between thetwo networks. Typically, the signaling would be Signaling System #7(SS7) messages. As will be described in detail later, signaling andcontrol system 100 is able to receive and process SS7 signaling toselect the appropriate VPI/VCI for cells entering a given network. Itpasses this information to the gateway 130 over control link 151.Control link 151 could be a bus, a data link or a signaling link. Thoseskilled in the art will appreciate various ways to couple signaling andcontrol system 100 with gateway 130. It is important to note thatsignaling and control system 100 and gateway 130 do not comprise an ATMswitch. Those skilled in the art will appreciate from the followingdiscussion how these components can be constructed and operated withoutthe complexities and cost of an ATM switch. Another advantage is thatthe gateway has single input/output throughput. This avoids manyproblems ATM switches encounter with multiple input and output ports.This also allows the gateway to concentrate traffic flowing into anetwork. In other words, the gateway is able to reorganize the trafficentering a network.

FIG. 2 depicts a version of the present invention. Shown are gateway 200composed of control interface 250, header mapper 210, ATM labelconverter 230 and ATM interfaces 220 and 240. Connections 263 and 264are ATM connections to ATM systems. Call/Connection Manager (CCM) 270 isa version of signaling and control 100 from FIG. 1. CCM 270 processessignaling and exerts control over the gateway 200 via link 260. Thislink could be any means of exchanging control information such as asignaling link, a data link, or a bus arrangement. Links 261 and 262provide signaling to CCM 270. An example would be an SS7 link, but othermeans to transfer signaling would be appreciated by one skilled in theart.

CCM 270 is a processing system that receives and processes signalingmessages. CCM 270 processes the signaling messages to select VPI/VCIassignments for gateway 200. In other words, it is a call processor. Itis different from a switch in that it does not have a switching fabric,and it does not carry actual user traffic. Typically, the processing isbased on a dialed number, and can include validation, routing, andbilling. CCM 270 would be functional to send control messages to thegateway 200. For call set up, the control message would instruct gateway200 to modify the VPI/VCI in incoming cells to the VPI/VCI selecteddynamically by CCM 270. For call tear down, the control message wouldinstruct gateway 200 to disassociate the incoming VPI/VCI from theoutgoing VPI/VCI. This releases the bandwidth associated with the call.CCM 270 is discussed in detail below.

Control interface 250 is functional to receive control messages andtransmit status information. It could be a conventionalhardware/software interface. Header mapper 210 is a logical table thatcontains the information associating incoming VPI/VCIs with outgoingVPI/VCIs. This table is dynamic and is updated on a call by call basis.ATM label converter 230 is functional to change the VPI/VCIs in incomingATM cells to new VPI/VCIs based on the table in header mapper 210.

ATM interface 220 is functional to accept incoming cells from connection263 and then send the cells through label converter 230. ATM interface240 is functional to accept converted cells from ATM label converter 230and transmit these cells on connection 264. These ATM interfaces arealso able to perform reciprocal processing for ATM traffic flowing inthe reverse direction.

Telecommunications signaling is used to set-up and tear down connectionsfor a call. Setting-up a connection would entail creating a series oflogically connected VPI/VCI communications paths from end to end. Thefollowing operation of the invention is described in terms of SS7, butthose skilled in the art are aware of other signaling systems that couldalso be used with the invention. Some examples of these other signalingsystems would be C7 and UNI.

Typically, the network providing cells to gateway 200 does not haveknowledge of the actual destination for these cells beyond gateway 200.This “first” network will also produce an Initial Address Message (IAM)associated with the call. The IAM contains information that can be usedto route the cells for the call. The IAM is transferred to CCM 270. CCM270 will process the IAM according to the requirements of the “second”network receiving cells from gateway 200. CCM 270 will select a newVPI/VCI based on the IAM.

In one embodiment, the system would operate as follows for a callincoming over connection 263. Typically, the network providing the callto gateway 200 will seize an available connection (VPI/VCI) to gateway200. This connection is represented by connection 263. CCM 270 willreceive the IAM produced in association with the call over link 261. Therouting label in the IAM contains a Circuit Identification Code (CIC).The CIC identifies the VPI/VCI in the incoming cells for the call. Inother words, the CIC in the IAM identifies the seized connection (inconnection 263) to gateway 200. CCM 270 will select the VPI/VCI forrouting the call over connection 264. CCM 270 then sends a controlmessage to control interface 250 through link 260. The control messagewill instruct gateway 200 to modify the VPI/VCI of the incoming cells sothey contain the VPI/VCI selected by CCM 270. Control interface 250responds with an acknowledgment over link 260 to CCM 270. In the case oferror conditions, the acknowledgment will be negative acknowledgment.Header mapper 210 will receive the instruction information from controlinterface 250 and will store this information for the duration of thecall. CCM 270 would also generate another IAM for transfer over link 262to the next node requiring a call message.

Cells for the call will arrive at ATM label converter 230 from ATMinterface 220 and connection 263. ATM label converter 230 will use theVPI/VCI of the incoming cells as the key to enter header mapper table210 to yield the new VPI/VCI. ATM label converter 230 will modify theVPI/VCI in the cell headers to the new VPI/VCI. The cells are thenforwarded to ATM interface 240 for transmission over connection 264.

At the end of the call, a release message (REL) is received by CCM 270over link 261. The REL will cause CCM 270 to begin call tear downprocedures. CCM 270 will send a control message to control interface 250over link 260. Control interface 250 will send the information to headermapper 210 disassociating the incoming and outgoing VPI/VCI for thecall. This will cause gateway 200 to terminate the call connection. CCM270 will then send an appropriate REL over link 262 to the next node.Those skilled in the art will appreciate that other procedures can alsobe used at the end of the call. For example, the CCM may allow theVPI/VCI assignment to remain for a specified duration.

Preferably, connection 264 would transfer these modified cells to an ATMcross-connect system that has pre-provisioned VPI/VCIs to potentialnetwork destinations. Because the VPI/VCI is selected in real time byCCM 270 based on the signaling and the routing configuration, gateway200 is able to implement SVCs on a call by call basis. It can beappreciated that by using the requirements for the network accepting thecells, CCM 270 and gateway 200 can implement SVCs for calls proceedingin both directions. It is also important to note that this can be donewithout the need for a complex ATM switch with signaling and callprocessing capability.

FIG. 3 shows another version of the invention. In this version, SS7signaling is used, but other signaling could be used in other versions.Shown are ATM system 300 and ATM system 350. ATM system 300 is comprisedof gateway 305, call/connection manager (CCM) 310, Signal Transfer Point(STP) 315, ATM cross-connect 320, and nodes 325, 330, 335, and 340. ATMsystem 350 is comprised of gateway 355, CCM 360, STP 365, ATMcross-connect 370, and nodes 375, 380, 385, and 390.

For the sake of clarity, the connections and links are not numbered.Virtual paths are shown (single lines) provisioned through ATMcross-connect 320 between gateway 305 and nodes 325, 330, 335, and 340.Virtual paths are shown provisioned through ATM cross-connect 370between gateway 355 and nodes 375, 380, 385, and 390. Gateway 305 andgateway 355 are connected by a virtual path as well. Signaling links areshown interconnecting the various components (as discussed above, thelink between the CCM and the gateway could also be a conventionaldatalink or bus arrangement). Note that cross-connects 320 and 370 donot require signaling. They are provisioned and do not needsignaling/switching capability on a call-by-call basis.

Gateway 305 and 355 have been described above. They modify the VPI/VCIsin ATM cells as instructed by control messages from the CCMs. CCM 310and 360 are described above and in detail below. They process signalingand select VPI/VCIs on a call by call basis. The selections are providedto the gateways. STPs 315 and 365 are known in the art. They routesignaling messages. ATM cross-connects 320 and 370 are known in the art.They route ATM cells based on a pre-provisioned routing configurationand the VPI/VCI in the cells. Nodes 325, 330, 335, 340, 375, 380, 385,and 390 are ATM devices. Any device that transmits or receives ATM cellsis contemplated by the invention. Some examples are ATM switches, ATMcross-connects, and ATM Customer Premises Equipment (CPE). Some of thesenodes may use signaling and some may not need signaling.

In operation, this version of the invention works as follows for a callfrom node 325 to node 385. Node 325 would recognize that the call didnot terminate within network 300 and would seize a connection to gateway355. This connection would be provisioned through cross-connect 320 andrepresented by the VPI/VCI in the cell headers. Gateway 305 is inactiveon this call and could even be omitted. It is shown to illustrate theGateway function could be implemented for calls passing in the otherdirection. Node 325 would also transfer an IAM to CCM 360 identifyingthe seized VPI/VCI. The IAM would be routed by STP 315 and STP 365 toCCM 360. It is important to note that ATM system 300 does not know therouting configuration of ATM system 350.

CCM 360 will process the IAM from Node 325 to select a VPI/VCI to node385. Gateway 355 has a provisioned virtual path to node 385 throughcross-connect 370. CCM 355 would select an available VCI within thatVPI. CCM 360 would identify both the VPI/VCI from gateway 305 and theVPI/VCI to node 385 in a control message to gateway 355. Gateway 355would modify the old VPI/VCI to the new VPI/VCI selected by CCM 360 andtransfer the modified cells to cross-connect 370. Based on itspre-provisioned routing configuration and the VPI/VCI selected by CCM360, cross-connect 370 would transfer these cells to node 385. Ifnecessary, CCM 360 would transfer an IAM to node 385 through STP 365.

It should be appreciated that the above procedure could be repeated formultiple calls between different nodes. This includes calls from network350 to network 300. The CCM, the gateway, and the cross-connect worktogether to provide SVCs on a call-by-call basis. This accomplishedwithout the cost or complexities of an ATM switch.

The Call/Connection Manager (CCM)

FIGS. 4-13 refer to a preferred embodiment of the signaling processor,also known as the CCM, but any processor which supports the requirementsstated for the invention would suffice. FIG. 4 depicts a signalingprocessor suitable for the invention. Signaling processor 400 wouldtypically be separate from the gateway, but those skilled in the artappreciate that they could be housed together and coupled in a busarrangement instead of being coupled by a data or signaling link.Signaling processor 400 may support a single gateway or support multiplegateways.

Signaling processor 400 includes Message Transfer Part (MTP) 410. MTP410 can be comprised of signaling point software that is known in theart. MTP 410 includes various levels known as MTP 1, MTP 2, and MTP 3.MTP 1 defines the physical and electrical requirements for a signalinglink. MTP 2 sits on top of MTP 1 and maintains reliable transport over asignaling link by monitoring status and performing error checks.Together, MTP 1-2 provide reliable transport over an individual link. Adevice would need MTP 1-2 functionality for each link it uses. MTP 3sits on top of MTP 2 and provides a routing and management function forthe signaling system at large. MTP 3 directs messages to the propersignaling link (actually to the MTP 2 for that link). MTP 3 directsmessages to applications using MTP 410 for access to the signalingsystem. MTP 3 also has a management function which monitors the statusof the signaling system and can take appropriate measures to restoreservice through the system. MTP levels 1-3 correspond to layers 1-3 ofthe open systems interconnection basic reference model (OSIBRF). MTP 410could also include Signaling Connection Control Part (SCCP) functions,as well as, TCAP, and ISUP functional interfaces. In addition, MTP 410may be equipped with ISUP timers that generate release messages orre-transmit messages where appropriate. If B-ISUP signaling is beingused, MTP 410 could also be equipped with B-ISUP capability. All ofthese elements are known in the art.

Also shown for signaling processor 400 are platform handler 420, bearercontrol 430, message handler 440, and record handler 450. MTP 410 couldbe connected to platform handler 420 by an ethernet interface supportingTCP/IP which transfers signaling messages from MTP 410 to platformhandler 420. Those skilled in the art will recognize other interfacesand protocols which could support these functions in accord with theinvention.

Platform handler 420 is a system which accepts ISUP messages from MTP410 and routes them to message handler 440. Message handler 440 is asystem which exchanges signaling with platform handler 420 and controlsthe connection and switching requirements for the calls. Bearer control430 handles bearer capabilities for the call. Record Handler 450generates call records for back-office systems.

In operation, ISUP messages are routed by MTP 410 to platform handler420. Platform handler 420 would route the ISUP messages to messagehandler 440. Message handler 440 would process the ISUP information.This might include validation, screening, and retrieving additional datafor call processing. Bearer control 430 would implement the bearercapabilities required, such as digital signal processing (DSP), throughcontrol messages to the appropriate network elements. Message handler440 would complete call processing. Message handler 440 would generatethe appropriate messages to implement the call and pass the messages toplatform handler 420 for subsequent transmission to the designatednetwork elements. Message handler 440 would also receive ISUP messagesfrom MTP 410 at the completion of the call. Message handler 440 wouldprocess these messages and generate subsequent messages to tear down thecall. Record handler 450 would obtain call information from messagehandler 440 and use this information to generate call records. The callrecords could be used for billing purposes.

Functional entities are well known in the art. Message handler 440includes at least the call control function (CCF) and the serviceswitching function (SSF). The CCF establishes and releases callconnections, and the SSF recognizes triggers during call processing bythe CCF and provides an interface between the CCF and the servicecontrol function (SCF). The SCF identifies services and obtains data forthe service, and is preferably housed in a remote database, such as anSCP. (As such, the SCF is not shown on FIG. 4.) Message handler 440 isable to control connections, recognize triggers, and access the SCF in aremote database.

Signaling processor 400 is comprised of hardware and software. Thoseskilled in the art are aware of various hardware components which cansupport the requirements of the invention. One example of a suchhardware is the FT-Sparc provided by Integrated Micro Products PLC. TheFT-sparc could use the Solaris operating system also provided byIntegrated Micro Products PLC. MTP 410 could be constructed usingcommercially available SS7 software interface tools. An example of suchtools would be SS7 interface software provided by either Trillium, Incor by Dale, Gesek, McWilliams, and Sheridan, Inc. Any data storagerequirements could be met with conventional database software systems.

Software for platform handler 420, bearer control 430, message handler440, and record handler 450 could be produced in the following manner.The Intelligent Network Conceptual Model (INCM) of the ITU-T Q.1200series could be mapped to Specification Design Language (SDL) of ITU-TZ.200 and Message Sequence Charts (MSC) of ITU-T Z.120. Variousdetection points and points-in-call in the INCM can be skipped tooptimize call processing. The SDL could then be compiled into C or C++and loaded onto the FT-sparc. The software is primarily comprised ofseveral static processes, instantiated processes (from staticprocesses), and communication channels between the processes.Preferably, the software processes would be partitioned into severaloperating system tasks. Further requirements for the software designwill become apparent in the following discussion.

The Platform Handler

Platform handler 420 is preferred, but is not required as its functionscould be handled by MTP 410 and/or message handler 440. Platform handler420 has messaging interfaces that exchange, buffer, dis-assemble, andre-assemble messages for MTP 410, bearer control 430, message handler440, and record handler 450. Platform handler 420 could exchange thesemessages over an ethernet—TCP/IP interface, but any technique fortransfer of messages is contemplated by the invention. Platform handler420 could also check the messages for basic flaws. Should more than onemessage handler be connected to platform handler 420, ISUP messagescould be allocated to the message handlers based on the SLS of theparticular ISUP message. Platform handler 420 also accepts routinginstructions from message handler 440 for routing certain ISUP messagesto particular select call model processes of message handler 440.

Platform handler 420 is also responsible for managing and monitoring CCMactivities. Among these are CCM start-up and shut-down, log-in andlog-off of various CCM modules, handling administrative messages (i.e.error, warning, status, etc.) from the CCM modules, and handlingmessages from network operations such as queries, configurationinstructions, and data updates. The connections to the various CCMmodules are shown. The connection to network operations is the manmachine interface which allows the CCM to be controlled and monitored byeither a remote or a local operator. Platform handler 420 has a processwhich retrieves configuration data from internal tables to initializeand configure the CCM. The CCM modules also have internal tables whichare used in conjunction with this procedure.

The Message Handler.

FIG. 5 depicts a version of the message handler. External connectionshave been omitted for the sake of clarity. Message handler 500 is shownand includes ISUP 510, call manager 520, feature manager 530, switchingmanager 540, and SCF access manager 550. The primary function of messagehandler 500 is to process ISUP messages for calls, generate subsequentmessages, and invoke services. As a result of its processing, messagehandler 500 is able to assign incoming access connections (CICs in SS7)to VPI/VCIs and instruct the gateway to provide SVPs and SVCs through anATM cross-connect system.

ISUP 510 receives generic ISUP messages from the platform handler andconverts them into specially formatted ISUP messages using receive 512.ISUP 510 reverses this process in transmit 514 for messages sent to theplatform handler. Receive 512 forwards formatted messages to callmanager 520. ISUP 510 also exchanges local management message with theplatform handler.

Call manager 520 could include the functionality specified in theIntelligent Network Call Model (INCM) of ITU-T Q.1214 which encompassesthe main functionality of the CCF. Call center 522 receives IAM messagesand creates an originating call model process for each IAM. Eachoriginating process is parameterized with data from its particular IAM.Additional origination processes can be created based on the IAM if itis a multi-party call. All of these originating processes arerepresented by originating processes 524.

An originating process will typically create a detection point process.All of the detection point processes created are represented bydetection point processes 526. Each originating process will also set-upa call control block containing data for the call. Each originationprocess will execute through a point-in call to a detection point. Whendetection points are encountered, and the originating process has notbeen programmed to skip them, a signal representing the detection pointis forwarded to the corresponding detection point process. As statedabove, call processing can be streamlined by skipping selected detectionpoints and points-in-call. When an originating process sends a detectionpoint signal to the corresponding detection point process, processing issuspended at the originating process until a response is received fromthe detection point process.

Detection point processes 526 provides a portion of the SSF and acts asa buffer between the call processes and feature manager 530. A detectionpoint process analyzes the detection point signal from the originationprocess to determine if is should be acted on or if it can be ignored.If the processing results in a service request or notification, acorresponding signal is sent to feature manager 530. Detection pointresponses from feature manager 530 are forwarded back to the appropriatecall process. Once call set-up has been authorized for the originatingprocess, a detection point process will also send a signal to callcenter 522 to create a terminating process.

These terminating processes are represented by terminating processes528. A terminating process creates and interacts with detection pointprocesses 526 much like an originating process. A terminating processalso creates a terminating call control block. ISUP information istransferred from the originating process for a call to the terminatingprocess for the call. The platform handler is instructed of theoriginating and terminating processes so that subsequent ISUP messagesrelated to that call can be transferred directly to the appropriateprocesses by the platform handler. Both originating and terminatingprocesses have a local database. For example, a termination processmight access local data to translate the NPA-NXX of a dialed number intothe VPI to a destination gateway.

The originating processes and terminating processes also exchangemessages with bearer control. Typically, these messages relate to DSPand gateway control. For calls that pass through two gateways (anoriginating gateway into the ATM network and a terminating gateway outof the ATM network), both an origination and termination process isrequired for each gateway—a total of four call processes. Thetermination process for the origination gateway will handle mapping theincoming VPI/VCI to the VPI/VCI through the ATM network. The terminationprocess for the terminating gateway will map the VPI/VCI through the ATMnetwork to an outgoing VPI/VCI. If only one gateway is used on the call(in and out of the network at the same gateway), only a singleorigination process and a single termination process is required.

The originating processes and terminating processes also exchangemessages with the record handler. Typically, these messages relate tobilling and operational measurements. Upon call tear down, the recordhandler receives the originating and terminating call control blocks forbilling purposes. These call control blocks typically would identify thefollowing: the call control block ID, the originating/terminatingprocess ID, the message handler, the originating LEC, the LEC trunkcircuit (CIC), the ATM virtual circuit, the ATM virtual path, thecaller's number, the dialed number, the translated dialed number, theoriginating line information, the ANI service class, the selected route,the number of the selected route, the SLS, the OPC, the DPC, the serviceindicator (SIO), reason of release, call status, and pointers toadjacent call control blocks. In addition, the call control block wouldalso contain the various times that signaling messages are received,such the address complete message (ACM), the answer message (ANM), thesuspend message (SUS), the resume message (RES), and the release message(REL). Those skilled in the art would be aware of other pertinent datato include.

Call manager 520 communicates with feature manager 530. Feature manager530 handles interaction of services for the call. Examples of serviceswould be 800 calls, PCS calls, and VPN calls, but there are many others.Feature manager 530 is comprised of feature center 532 and featureprocesses 534. Feature center 532 receives the detection point messagesfrom the detection point processes 526. Feature center 532 then createsa feature process for each call. These processes are represented byfeature processes 534. The feature process will determine if additionaldata is needed for the detection point. If so, a signal is sent toswitching manager 540. Responses from switching manager 540 are sent tothe appropriate detection point process by the feature process for thecall.

In this embodiment, the feature process sends all such service signalsto switching manager 540. In other embodiments, services may besegregated into “IN” and “non-IN” services, the feature process wouldthen have to select between an “IN” switching manager or a “non-IN”switching manager when sending service signals to switching manager 540.

Switching manager 540 is comprised of switching center 542 and switchingprocesses 544. Switching manager 540 creates a switching process foreach service required on the call. These switching processes arerepresented by switching processes 544. A switching process willcommunicate directly with the associated feature process for the call.The switching process will also interface with the SCF. As stated above,the SCF provides the service processing for the call and is preferablylocated at a remote database. A typical example of accessing SCF wouldbe to send a TCAP query to a Service Control Point (SCP) for an “800”number translation. In order to access the SCF, the switching processwill use SCF access manager 550. SCF access manager 550 is comprised ofencoder 552 and decoder 554. Encoder 552 converts signals from switchingprocesses 544 into the proper format for SCF access. Decoder 554converts messages from the SCF back into the format for switchingprocesses 544. SCF access manager 550 would typically access the SCFover standard communications links. One example would be an SS7 linkusing the TCAP/INAP/ASN.1 protocol specified by the ITU. If SS7 is used,SCF access manager 550 could forward its TCAP messages to the MTPfunction (MTP 410 of FIG. 4) for subsequent transfer to an STP and SCP.

From the above discussion, it should be clear that message handler 500is comprised of static processes identified as “centers” that createspecific processes for each call. Once created, these specific callprocesses communicate directly with one another to accomplish callprocessing.

Bearer Control and the Record Handler

As stated bearer control will handle DSP requirements and gatewaycontrol. An example of DSP requirement would be to adjust the decibellevel. An example of a gateway control would be a VPI/VCI assignment.After a release message on a call, the originating and terminatingprocesses will forward the information in the call control block torecord handler 450. Record handler 450 will use the call control blockto create a billing record. The call control block would containinformation from the ISUP messages for the call and from CCM processing.From the address complete message (ACM), the call control block wouldinclude the routing label, CIC, message type, and cause indicators. Fromthe answer message (ANM), the call control block would include therouting label, CIC, message type, and backward call indicators. From theinitial address message (IAM), the call control block would include therouting label, CIC, message type, forward call indicators, user serviceinformation, called party number, calling party number, carrieridentification, carrier selection information, charge number, genericaddress, origination line information, original called number, andredirecting number. From the release message (REL), the call controlblock would include the routing label, CIC, message type, and causeindicators. From the suspend message (SUS) or the pass along message(PAM), the call control block would include the routing label, CIC, andmessage type. Those skilled in the art are familiar with other pertinentinformation for a billing record and appreciate that some of thisinformation could be deleted. The billing record will be forwarded byrecord handler 450 to a billing system over a billing interface. Anexample of such an interface is an ethernet—FTAM protocol.

Call Processing

SS7 messaging is well known in the art. SS7 ISUP messages containnumerous fields of information. Each message will have a routing labelcontaining a destination point code (DPC), an origination point code(OPC), and a signaling link selection (SLS) which are used primarily forrouting the message. Each message contains a circuit identification code(CIC) which identifies the circuit to which the message relates. Eachmessage contains the message type which is used to recognize themessage. ISUP messages also contain mandatory parts filled with fixedlength data and variable length data, in addition to a part availablefor optional data. These parts vary from message type to message typedepending on the information needed.

The initial address message (IAM) initiates the call and contains callset-up information, such as the dialed number. IAMs are transferred inthe calling direction to set up the call. During this process, TCAPmessages may be sent to access remote data and processing. When the IAMshave reached the final network element, an address complete message(ACM) is sent in the backward direction to indicate that the requiredinformation is available and the called party can be alerted. If thecalled party answers, an answer message (ANM) is sent in the backwarddirection indicating that the call/connection will be used. If thecalling party hangs up, a release message (REL) is sent to indicate theconnection is not being used and can be torn down. If the called partyhangs up, a suspend message (SUS) is sent and if the called partyreconnects, a resume (RES) message keeps the line open, but if their isno re-connection, a release message (REL) is sent. When the connectionsare free, release complete messages (RLC) are sent to indicate that theconnection can be re-used for another call. Those skilled in the art areaware of other ISUP messages, however, these are the primary ones to beconsidered.

In the preferred embodiment, call processing deviates from the basiccall model recommended by the ITU, although strict adherence to themodel could be achieved in other embodiments. FIGS. 6-13 depict messagesequence charts for the call processing in one embodiment. Messagesequence charts are known in the art, and are a recognized format todepict call processing. At the top of the chart, the basic elements ofthe CCM are shown—the platform handler, the message handler, the bearercontrol, and the record handler. The blocks below the message handlerindicate the processes for the message handler. Further specification atthe process level for the platform handler, the bearer control, and therecord handler is not required for this discussion. The charts are readdown in a chronological sequence. Blocks indicate tasks performed by theprocess named above. Arrows indicate messages exchanged between theprocesses or the creation of a new process by an existing process.

The sequence starts on FIG. 6 with an ISUP message at the platformhandler. The platform handler forwards the message to the ISUP receiveprocess of the message handler. If the ISUP message is an IAM, the ISUPreceive process forwards the IAM to the call center. The call center hadbeen in the “origination null” point-in-call, but the IAM causes thecall center to create an originating call process parameterized withcontents of the IAM. The originating process then executes through the“authorize origination attempt” point-in-call. This typically entailsANI validation in a look-up table, but prior to the look-up, callinformation is checked to determine if ANI validation is required. Forparticular types of calls, i.e. “800” calls, origination is authorizedwithout ANI validation.

Once origination has been authorized, the originating process creates adetection point process and transmits a signal to the detection pointprocess that origination has been authorized. The detection pointprocess returns a message instructing the origination process to executethrough the “analyze information” point-in-call, although a detectionpoint could be programmed at this point if desired. Continuing on toFIG. 7, “Analyze information” typically entails verifying that thedialed number is legitimate and checking call information for anyapplicable services. A few examples of a services are “800” and PCS. Inthis example, no services are required for the call—the call is atypical POTS call. Once the analysis has been accomplished, theoriginating process sends a “analyzed information” message to thedetection point process. Typically, the detection point process returnsa “resume” message to the originating process, but detection pointscould be programmed here if desired.

The resume message causes the origination process to execute through the“routing and alerting” point-in-call. This typically entails translatingthe dialed number to select a destination address. For example, theNPA-NXX of the dialed number could be used in a look-up table to yieldthe address of the terminating gateway and the device that shouldreceive the call from the gateway. The origination process will alsosend a message to the call center to create an terminating call process.The terminating call process is provided with the identity of theoriginating process. The terminating process also creates a detectionpoint process to handle the detection points it encounters. For purposesof clarity, this is indicated along the same line as the originatingprocess detection point, although it should be understood that eachprocess communicates with its corresponding detection point.

Continuing on to FIG. 8, the terminating process executes through the“authorize termination attempt” point-in-call. This typically entailsverifying that an ATM connection to another gateway can be attempted.For example, the CCM and the gateway at the terminating end must beoperational to handle the call. Once termination is authorized, anauthorized message is sent to the detection point process, which returnsa resume message to the termination manager (unless a detection point isprogrammed into the detection point process.)

The terminating process will then execute through the “select facilityand present call” point-in-call. This typically entails selecting theactual VPI/VCI and outbound connection for the call. The destination hasalready been specified during the “routing” point-in-call, so theVPI/VCI and point codes can be looked-up accordingly. The terminatingprocess will then send a message to bearer control requesting gatewaycontrol. Bearer control would then create a message for the originatinggateway identifying the connections and devices relevant to the call.Bearer control would respond that gateway control was handled.Continuing on to FIG. 9, the terminating process would then construct anIAM for transmission to the downstream CCM at the terminating gateway.As discussed above, this message could be coded such that the downstreamCCM could skip detailed call processing. The IAM would be provided tothe ISUP sender and a formatted IAM would be provided to the platformhandler for subsequent transmission to the downstream CCM.

On a typical call, the next message that would be received by the CCMthat is related to the call would be an Address Complete Message (ACM)signifying that the terminating end of the call had the informationrequired to complete the call. The external device would send an ACMback to the terminating CCM which would pass on an ACM to theoriginating CCM. These procedures at the terminating CCM are notdepicted in the message sequence chart. The message sequence chartcontinues with the ACM arriving at the originating CCM.

The ISUP receive process would forward the ACM to the terminatingprocess. The terminating process would execute through the “alerting”point-in-call and would send ACM information to the originating process,which would also execute through the “alerting” point-in-call. Alertingentails alerting the users that a connection is available—i.e. ringing atelephone. Typically, no specific activity is required for “alerting”,but detection points could be inserted into the process if desired. Theoriginating process would forward an ACM to the ISUP sender which wouldprovide a formatted ACM to the platform handler for subsequenttransmission to devices at the origination side of the call.

On the typical call, an Answer Message (ANM) will be transferred fromthe terminating side of the call to the origination side of the callwhen the called party answers the phone. The ANM is received by theplatform handler and forwarded to the ISUP receive process whichforwards its version to the terminating process. Continuing on to FIG.10, the terminating process executes though the “active” point-in-calland sends ANM information to the detection point process. Typically, thedetection point process will return a resume message, although detectionpoints could be included here if desired. The terminating process alsosends a gateway control message to bearer control to facilitatecut-through on the call at the gateway. A acknowledgment response issent back to the terminating process from bearer control. Theterminating process also sends ANM information to the originatingmanager, which also executes through the “active” point-in-call. Theoriginating process also sends an answer message to the detection pointprocess and a partial call control block to the record handler.Typically, the detection point process will send a resume message backto the origination process. The originating process would forward an ANMto the ISUP sender which would provide a formatted ANM to the platformhandler for subsequent transmission to devices at the origination sideof the call. At this point, the call is in progress.

The message sequence continues with the receipt of a release message(REL) after the caller or called party hang up. As stated above, if thecalled party hangs up, a suspend message (SUS) is sent before the callis released, but if the caller hangs up, only an REL is sent. Forclarity, the chart picks up with an REL arriving from the terminatingside of the call. The REL is received by the platform handler andtransferred to the ISUP receive process, which provides its version ofthe message to the terminating process. (Had the REL been from theoriginating side, it would have been provided to the originatingprocess.) The terminating process executes through the “disconnect”point-in-call. Continuing on FIG. 11, the terminating process sends RELinformation to the originating process. The originating process wouldforward an REL to the ISUP sender which would provide a formatted REL tothe platform handler for subsequent transmission to devices at theorigination side of the call. In response to the REL, the terminatingprocess will forward a Release Complete Message (RLC) to the ISUP senderwhich would provide a formatted RLC to the platform handler forsubsequent transmission to the device that sent the REL. The RLCacknowledges the REL and signifies that the call connections may be torndown and re-used. The terminating process also sends a gateway controlmessage to bearer control to cause the relevant VPI/VCI to be torn down,and receives an acknowledgment response from bearer control.

The next message will typically be an RLC in response to the REL sent tothe originating side of the call. The RLC is received by the platformhandler and forwarded to the ISUP receive process. ISUP receive providesits version of the message to the originating process. This causes theoriginating process to forward its final call control block to therecord handler. The originating process also provides RLC information tothe terminating process. This causes the terminating process to send itsfinal call control block to the record handler. The record handlerresponds to each process with an acknowledgment response. Continuing onto FIG. 12, tear down messages are sent by the originating process andthe terminating process to their respective detection point processes.Typically, no detection points will be programmed and the originatingprocess, the terminating process, and the detection point processes willterminate and be cleared from the CCM.

FIG. 13 also depicts a modified excerpt from the message sequence chartsabove. The modification is for a call that requires services. Servicesmight include N00 or VPN calls, but many other services are known. Inthis embodiment, an SCP is accessed to provide information to implementthe service. As shown, call processing picks up where the detectionpoint process for either the originating process or the terminatingprocess analyzes a detection point and determines that a service isrequired. Typically, this is done by examining the dialed number and thecaller's number. Those skilled in the art are aware of how services canbe determined from call information.

If it is determined that a service should be applied to the call, thedetection point process sends detection point message to the featurecenter that causes the feature center to create an feature process. Thefeature process will be parameterized with call information and willsend a detection point message to the switching center. In someembodiments, the feature process will choose between “IN” services and“non-IN” services and send the detection point message to thecorresponding switching center. Upon receiving the message, theswitching center creates a service process for each service to beapplied to call. The service process formulates a request for serviceinformation and forwards it to the encoder of the SCF access manager.The encoder produces a TCAP message and transmits it over theappropriate link to a remote SCF. (possibly through the platform handlerand/or the MTP interface). The remote SCF will return a response to thedecoder. The response is formatted for the service process and sent toit. The service process takes the response and formulates an analyzeinformation message that is transferred back through the feature processto the detection point process. The detection point process transfersthe analyze information message to the applicable originating orterminating process. Subsequent call processing remains the same asdiscussed above. At call tear down, the feature process and theswitching process are cleared from the CCM.

An example of the above scenario would be for an “800” call. The CCMwould recognize that the “800” in the called number required serviceapplication. As a result, it would generate and transmit TCAP query toan SCP requesting an “800” translation. The SCP would process the queryand translate the “800” number into a POTS number. The SCP would returnthe POTS number to the requesting CCM. The CCM would then process thePOTS number as it would for a standard POTS call.

In some embodiments, the CCM processes SS7 signaling messages toaccomplish the following functions: validation, routing, and billing.SS7 messages are well known in the art. The following sections discussSS7 processing, but those skilled in the art will recognize variationsthat are also contemplated by the invention. In SS7, the routing labelsof the messages are used to correlate messages to calls. Contemporaneousmessages with the same OPC, DPC, and CIC relate to the same call.

To validate a call, the routing label of messages should be checked. TheService Indicator should be checked to distinguish between an incomingmessage from outside of the network or a message from a network CCM. TheDestination Point Code is screened to ensure the destination of the SS7message is actually destined for the CCM. The Originating Point Code isscreened to ensure the originating point code is allowed in the CCM. TheMessage Type is screened to ensure that the type of message is allowedin the CCM and that there are no protocol violations associated with themessage.

Both the Circuit Reservation Message (CRM) and the IAM should have theSatellite Indicator screened to ensure that the limit on the number ofSatellites in a circuit has not been exceeded. This will be on a trunkgroup by trunk group basis. The REL automatic congestion level will bescreened to see if congestion arises. The CCM should then control callsto the associated network elements until the congestion abates. Fornon-call associated messages, the circuit group supervision message typeindicator will be screened to compare the state of the circuits with theinstructions incoming in the messages.

The IAM will receive additional treatment for validation. InformationTransfer Capability will be screened to ensure that the connection forthe call is capable of handling the transfer rate requested. The CodingStandard will be screened to ensure that the standard is coded 00. Allothers will be rejected. Transfer Mode will be screened to ensure thatthe mode is coded 00 for 64 Kbit/second calls. User Layer Protocol IDand the Rate field will be screened to ensure that there is no rateadaptation required for the call. The Network ID Plans and Digits, willbe screened to ensure that the carrier identification field and thetransit network carrier identification field is in the correct format.The Circuit Code will be screened to allow callers with the correctmeans of dialing to access the network.

The CCM will check the Hop Counter in the IAM to determine if it hasreached its limit as set by this field (range 10 to 20 with a default of20). If it has not, the CCM will increment the parameter. If it hasreached the determined count, the CCM will send a release message backwith a cause of “exchange routing error” to tell the preceding switchthat the IAM has reached its limit in hops. If this field is left blank,the CCM will not increment the counter parameter and pass the IAMunchanged.

The IAM Called Party Number field should be handled as follows forvalidation. Nature of Address will tell the CCM what type of number wasdialed for the called number. The screening of this field will be for anon-NPA number. If that occurs, the CCM will need to add the NPA fromthe Trunk Group to the call control block. Numbering Plan will bescreened to check what type of plan the incoming called party numberuses. The only allowable plans are Unknown and ISDN numbering plans. Allothers should be disallowed. Digits Field will be screened for thenumber of digits using the Nature of Number, Odd/Even, and Digits Fieldsto determine the correct number of digits.

The IAM Calling Party Number and Charge Number fields should be handledas follows for validation. Nature of Address will be screened to ensurethat the calling party's number is in the proper format. PresentationAllowed/Restricted will be screened to check for N00 calling. NumberingPlan will be checked to ensure that the numbering plan is set at eitherunknown or ISDN numbering plan. Digits Field will be checked to ensurethat there is enough digits for an ANI that can be billed. These digitswill be validated in an ANI table for call authorization.

Routing is primarily accomplished by processing the IAM. Called PartyNumber—Nature of Address, Digits—This will tell the CCM what type ofcall this is. It will differentiate 0+, test calls, and Internationalnumbers from normal 1+ calls. The Calling Party's Category tells the CCMthat the call is a test call with different routing than a normal call.The Carrier Identification Plan will be used to determine if the CCMreceives the Carrier Identification Code of another carrier, since theCCM may wish to route the call based on the subscribers choice ofcarriers. The IAM Carrier Selection Information is used to route thecall based on whether the subscriber was presubscribed or dialed thecarrier access number. The IAM Originating Line Information will enablethe CCM to route based on what type of originating line is being usedfor this call. An example is if a payphone makes a 1+call, the CCM willbe able to route the call directly to an operator for billingarrangements. The IAM Transit Network Selection fields will indicate theCarrier Identification Code of the International Carrier that isrequested by the subscriber, so the CCM can route the international callto the correct switch. The Circuit Code will tell the CCM how the codewas dialed. If the subscriber dialed an access code for a differentinternational carrier, the CCM could route the call to an operatorcenter for processing.

The IAM Called Party Number fields are handled as follows for routing.Nature of Address Indicator tells what type of call is being requested.This will include 0+ and 0− calls, international calls (operator and nonoperator calls), cut through, and 950 types of calls. With thisinformation, the CCM can route the call directly to the internationalgateway or operator center without looking at the rest of the message.For normal 1+ calls, the Odd/Even field will be used with the digitsfields to determine the number of digits. Numbering Plan field will beused to route calls differently if it has a “Private Numbering Plan”value in the field. Digits Field will be the digits that will be used toroute the call through the network using table look-ups. Typically, thedigits field houses the dialed number.

Billing will be based on the Call Control Blocks (CCBs) created by thecall processes. A portion of these records are transferred from messagesreceived by the CCM. The CCBs are discussed above. When the CallingParty Number is present in the IAM and there is no Charge Numberpresent, the Calling Party Number is used to bill the call. If theCharge Number is present in the same message, then the Charge Numberwill be used for billing instead of the Calling Party Number. Variousmessages need to be tracked to measure the duration of the call. Theseinclude the IAM, ACM, ANM, SUS, REL, and RLC. The causes associated withthese messages should also be considered.

The invention allows switching over an ATM fabric on a call by callbasis. This allows efficient high capacity virtual connections to beexploited. Advantageously, the invention does not require signalingcapability in an ATM switch. The invention does not require callprocessing capability in an ATM switch. This enables networks toimplement ATM switching without these sophisticated ATM switches thatsupport high volumes of calls. It also avoids the cost of theseswitches. Relying on ATM cross-connects is advantageous because ATMcross-connects are farther advanced than ATM switches, and thecross-connects require less administrative support.

Those skilled in the art will appreciate variations of the abovedescribed embodiment. In some embodiments, other signaling, such as C7or UNI signaling could be used instead of SS7. Other embodiments mightmake use of network management techniques to control gateway 200. Anexample would be the use of a Telecommunications Management Network(TMN) to control the gateway in situations where slowly changing VPI/VCImappings are needed. Those skilled in the art will also appreciate thata gateway could be implemented within a single network at points wheredynamic VPI/VCI conversion is desirable. Gateways between multiplesuccessive networks could also be employed. In addition to theseembodiments, other variations will be appreciated by those skilled inthe art. As such, the scope of the invention is not limited to thespecified embodiments, but is only restricted to the following claims.

1. A method of processing a call from a first communication network, themethod comprising: in a call processor in a second communicationnetwork, receiving a signaling message from the first communicationnetwork wherein the signaling message indicates a first identifier thatrepresents a connection through the first communication network to thesecond communication network; in the call processor, processing thesignaling message to select a second identifier; in the call processor,transferring a control message indicating the first identifier and thesecond identifier; in a gateway in the second communication network,receiving the control message; in the gateway, receiving a usercommunication from the first communication network wherein the usercommunication has a header indicating the first identifier, and inresponse to the first identifier and the control message, modifying thefirst identifier in the header to the second identifier; andtransferring the user communication from the gateway through the secondcommunication network to a destination node in response to the secondidentifier in the header of the user communication.
 2. The method ofclaim 1 wherein the second communication network has a routingconfiguration and the first identifier in the header of the usercommunication is not compatible with the routing configuration.
 3. Themethod of claim 2 wherein the second identifier in the header of theuser communication is compatible with the routing configuration andwherein transferring the user communication through the secondcommunication network to the destination node in response to the secondidentifier in the header of the user communication comprisestransferring the user communication through the second communicationnetwork to the destination node based on the routing configuration. 4.The method of claim 1 wherein the first communication network receivesthe user communication with the first identifier in the header fromcustomer premise equipment.
 5. The method of claim 1 wherein thedestination node comprises customer premise equipment.
 6. The method ofclaim 1 wherein the destination node comprises another gateway.
 7. Themethod of claim 1 wherein processing the signaling message to select thesecond identifier comprises processing a dialed number in the signalingmessage to select the second identifier.
 8. The method of claim 1wherein the gateway has single input/output throughput.
 9. The method ofclaim 1 wherein the user communication comprises an asynchronoustransfer mode cell.
 10. The method of claim 1 wherein the call processordoes not include a switching fabric.
 11. A second communication networkto process a call from a first communication network, the secondcommunication network comprising: a call processor configured to receivea signaling message from the first communication network wherein thesignaling message indicates a first identifier that represents aconnection through the first communication network to the secondcommunication network, process the signaling message to select a secondidentifier, and transfer a control message indicating the firstidentifier and the second identifier; a gateway configured to receivethe control message, receive a user communication from the firstcommunication network wherein the user communication has a headerindicating the first identifier, and in response to the first identifierand the control message, to modify the first identifier in the header tothe second identifier; and a routing system configured to transfer theuser communication from the gateway to a destination node in response tothe second identifier in the header of the user communication.
 12. Thesecond communication network of claim 11 wherein the routing system hasa routing configuration and the first identifier in the header of theuser communication is not compatible with the routing configuration. 13.The second communication network of claim 12 wherein the secondidentifier in the header of the user communication is compatible withthe routing configuration and wherein the routing system is configuredto transfer the user communication to the destination node based on therouting configuration.
 14. The second communication network of claim 11wherein the first communication network receives the user communicationwith the first identifier in the header from customer premise equipment.15. The second communication network of claim 11 wherein the destinationnode comprises customer premise equipment.
 16. The second communicationnetwork of claim 11 wherein the destination node comprises anothergateway.
 17. The second communication network of claim 11 the callprocessor is configured to process a dialed number in the signalingmessage to select the second identifier.
 18. The second communicationnetwork of claim 11 wherein the gateway is configured with singleinput/output throughput.
 19. The second communication network of claim11 wherein the user communication comprises an asynchronous transfermode cell.
 20. The second communication network of claim 11 wherein thecall processor does not include a switching fabric.